To deliver any software application product, feature analytics are usually needed to manually explore, specify, prioritize software features to implement. Without right features, the software may fail to win in the market.
FIG. 1 shows one traditional feature analysis approach 50 to cognitive (software) engineering. Here, a feature analyst 52 largely receives non-guided communications to generate features for a software product, e.g., for a music player, what potential features are needed to be provided? Such non-guided communications received by the analyst may include but are not limited to: communications via mails/e-mails 60, communications via meetings 63, communications via phones 66, and generates a feature analysis report 75. Such a process 50 depicted in FIG. 1 heavily depends on the expertise, capability, and even body status of requirement analytics. The process is usually with low efficiency and generates ineffective feature report (i.e., of unguaranteed quality).
Further approaches focus on validation of given specific requirements on specific characteristics (e.g., confliction) and may focus on exploring proper requirement analysis for special systems (e.g., multi-agent based applications).
In one known approach, there is applied automatic plan technology to help capture/understand a given requirement specification more accurately and completely. However, this prior art approach requires a given requirement specification from users.
Additionally, one approach proposes to use checklists to enable a conscious and systematic approach to identify software requirements, e.g., to define a requirement more accurately.